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[57] ABSTRACT 

The present invention extends the PNNI protocols to support 
hierarchical multicast routing and signaling for ATM net- 
works. The invention utilize s an extens ion to a core-based 
tree algorithm, tostoadiof falsing^ 
mai ntaire ra dfinj fe^ 

hiefa'feriy. The advantage of this is that one single core node 
is not overloaded. Additionally, this if^ejses^aulytoter^upej 
because there are no single points of failure. As would be 
understood, the present invention is ffigMyilsealelible 
because of the hierarchical nature of PNNI. In addition, the 
scheme supports multiple senders and dynamic membership 
changes to the multicast group. Quality of service require- 
ments can be negotiated during connection setup and are 
guaranteed during the course of the connection. Though 
some additionallto^lo^eallMoTiffiatLon'has to be flooded in 
the peer-groups to ^com pute^efficient multicast routes, the 
overheads to the connection management are minimal. The 
'multfc^it^ the cost of the tree 

is comparable to the cost of the Steiner Tree computed using 
some standard heuristics. 

23 Claims, 5 Drawing Sheets 
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SYSTEM AND METHOD FOR 
HIERARCHICAL MULTICAST ROUTING IN 
ATM NETWORKS 

FIELD OF THE INVENTION 

The present invention relates generally to multicast opera- 
tions in communications networks, and more particularly to 
a hierarchical multicast routing scheme in an ATM network 
architecture. 

BACKGROUND OF THE INVENTION 

^Multicastin'g (or point-to-multipoint routing) ifiVAsyn^ 
chron^u^Trim^r^ 
sejding^^ 

cusing^a'smgle'conne^cfionr^A straightforward approach for 
multicasting would establish point-to-point connections 
from a source to each of the destinations and the ATM cells 
would be sent to the respective destinations using these 
connections. This approach does not work well, however, for 
applications like video conferencing because such applica- 
tions require very high bandwidth. Moreover, this approach 
does not scale well, as the number of multicast applications 
and the number of destinations per connection increase. A 
significant challenge is to develop a highly scaleable scheme 
for multicasting which is also efficient with respect to a 
combination of factors like bandwidth consumption and 
delay. A further challenge is to guarantee some quality-of- 
service (QoS) for each of the connections. 

A first step in finding ef£'cienUschemes?for multicasting is 
to define a model for the problem. Networks are generally 
modeled as weighted, undirected graphs. The nodes of the 
graphs represent the switching systems and the hosts. Edges, 
on the other hand, represent the physical links. The weight 
associated with an edge, in some way, reflects the cost of 
using the link (in terms of delay, bandwidth consumption or 
distance). The problem of finding a scheme for multicasting 
reduces to finding a subgraph of the network graph satisfy- 
ing certain properties. The subgraph must be a tree with the 
source as the root and the destinations as either internal 
nodes or the leaves. As would be understood by a person 
skilled in the art, this tree is called the Steiner Tree of the 
graph for the given source and destination nodes. Minimiz- 
ing the cost of the Steiner Tree while satisfying the QoS 
constraints results in efficient multicasting. It must be noted 
that the cost of the Steiner tree is the sum of the cost of the 
individual links that are part of the tree. It has been shown 
that finding the optimal Steiner Tree is quite a complex 
problem. But there exist good heuristics, whose solutions 
can be bounded by a factor of two times the cost of the 
optimal solution. The problem of finding the efficient tree is 
called the routing problem for multicasting. In connection- 
oriented networks, a connection has to be established before 
the ATM cells can be transmitted. This is achieved using 
signaling. The problem of efficient connection establishment 
is termed as the signaling problem in ATM networks. 

Multicasting applications can themselves be modeled in 
several ways, depending on their degree of complexity. The 
simplest model, referred to herein as Model 1, has a single 
source sending ATM cells to a fixed set of destinations. In 
this case, the Steiner Tree can be computed statically before 
the connection is set up and ATM cells can be transmitted 
along the links corresponding to edges of the Steiner Tree. 

A slightly more complex model, referred to as Model 2, 
can handle dynamic changes to the set of destinations during 
the course of the multicast. The destinations are addressed 
collectively by a multicast group address. ATM cells desig- 
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nated to the group address are forwarded to all the destina- 
tions that have registered membership to the group address. 
Changes in the destination set result in the recomputation of 
the Steiner Tree. 

The above models have only a single user sending data to 
the multicast group. The complexity of the multicast 
increases if there are several senders per multicast group 
(also known as multipoint-to-multipoint connection). In this 
case, there can be a separate Steiner tree for each sender. 
However, this would not be scaleable because of the 
increased complexity of maintaining information about each 
Steiner tree. One way of overcoming this problem is to 
associate one tree with the multicast group. One node in the 
tree, called the core node, is chosen to receive the ATM cells 
from all senders. The core node is then responsible for 
sending the cells to all the destinations in the tree. Though 
this scheme is scaleable, the main problem here is the 
overloading of the core node, which leads to performance 
degradation. 

Multicast routing in the Internet 

In connectionless networks like the Internet, the multi- 
casting problem is slightly simplified because there is no 
additional overhead of connection setup and management. 
But, QoS requirements are hard to guarantee because con- 
nectionless networks provide only best-effort services. Pro- 
tocols like RSVP (Resource reSerVation Protocol) provide 
the means to reserve resources, but implementation of such 
a scheme is not yet practical. 

In connectionless environments like the Internet, several 
approaches for multicasting have been proposed in the prior 
art. The simplest approach is termed flooding or truncated 
broadcast. Here, packets are flooded to all routers in the 
network and the routers have the responsibility of multicast- 
ing the packets within their local subnets. Duplicate packets 
are discarded by each router. If a "shortest -path" criterion is 
used to decide which packets to flood and which packets to 
discard, the resulting scheme is called Reverse-Path Flood- 
ing (RPF). The flooding mechanism is inherently based on 
the hop-by-hop routing scheme in the connectionless Inter- 
net. The main disadvantage with flooding is that several 
redundant packets are transmitted on the links. For high 
bandwidth video applications, this can lead to congestion in 
the network, especially when routers have to maintain a 
separate tree for each sender of a multicast group. 

The idea of a Core -Based Tree (CBT) requires the main- 
tenance of only one tree per multicast group. Each multicast 
group has a core node associated with it. This node is always 
a part of the multicast tree for that group. A node which 
wants to receive packets sent to that group must register with 
the core node. The core node forms a multicast tree with all 
the destination nodes. When a source wants to send packets 
to the group, it first sends a packet towards the core node. If 
any of the intermediate nodes is already on the multicast 
tree, it then forwards the packet on the links of the multicast 
tree. The main advantage here is that only one tree is 
maintained per multicast group which makes it very scale- 
able. On the other hand, if there are many senders and all of 
them send the packets to the core node, then the core node 
can be a bottle-neck. The core node is also the single point 
of failure, hence this algorithm is not fault- tolerant. 

Many of the schemes in the prior art for multicasting are 
designed for the connectionless model of the Internet. In the 
future, the Internet will be based on the connection-oriented 
native ATM networks. Thus, schemes for multicasting in the 
ATM networks need to be developed. Several higher layer 
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multicasting applications have been envisaged with under- 
lying ATM networks. One such application by IETFs 
IP-over- ATM working group (IPATM) maps the connection- 
less IP multicast service over native ATM networks. The 
scheme uses the concept of a Multicast Address Resolution 5 
Server (MARS). All the nodes that want to be members of 
a particular group register with the MARS. To send data to 
the multicast group, two schemes have been proposed. In the 
multicast server scheme, there is a multicast server associ- 
ated with each multicast group and there may be more than 10 
one server to take care of load balancing and fault-tolerance. 
The multicast servers also register with the MARS. The 
sender contacts the MARS and gets the identity of the server 
where the MARS then establishes connection with the 
server. The server has a point-to-multipoint connection with 15 
all the destination nodes and is responsible for transmitting 
the data to all the destinations. New destinations also contact 
the MARS and then join the server's point-to-multipoint 
connection. In the absence of a multicast server, the MARS 
returns the list of all the destinations to the sender. The 20 
sender then sets up a point-to-multipoint connection with all 
the destinations. This scheme assumes the existence of an 
underlying point-to-multipoint protocol for native ATM net- 
works. 

Other applications like video-conferencing require the 25 
underlying system to support multicasting while guarantee- 
ing certain quality of service like consistent bandwidth, 
bounded delays and bounded delay-jitter. It is not easy to 
provide end-to-end guarantees and quality of service when 
a hop-by-hop routing mechanism is used. This is the main 30 
motivating factor for developing protocols for multicasting 
in ATM networks. 

Routing and Signaling in ATM Networks 

Routing and signaling are two main components in the 35 
design of a connection-oriented protocol. Routing protocols 
help in the computation of an efficient path for the specific 
connection. Signaling protocols assist in efficient establish- 
ment and management of the connection. ^ 

A signaling mechanism handles set-up, maintenance and 
clearance of connections between a source and possibly 
more than one destination. During connection setup, the 
resources on the links are also reserved so that quality of 
service(QoS) can be guaranteed for the connection. The 45 
ATM Forum has proposed ATM UNI Signaling mechanisms 
at the user network interface. 

The basic point-to-point signaling protocol is a two-way 
hand-shaking mechanism. Some signaling messages are 
global in nature, that is, they are propagated from the source 50 
end to the destination end. Local acknowledgment messages 
are used to acknowledge the receipt of global messages as 
they pass from one node to another in the network. The 
source (which is an ATM end-system) sends a SETUP 
message to the switching system over the User-Network 55 
Interface. This message includes information like destina- 
tion address and the QoS requirements. The network for- 
wards the SETUP message towards the switching system to 
which the destination end -system is attached. Resources are 
reserved en route to guarantee QoS requirements. go 

When the SETUP message reaches the destination, the 
destination can either accept the connection or reject it for 
any one of various reasons. For example, one important 
reason could be that QoS guarantees cannot be fulfilled. If 
the connection is rejected, a RELEASE message is sent from 65 
the destination which propagates back to the source, where • 
all the resources that were previously reserved are released. 



4 

If the connection is accepted, a CONNECT message is sent 
from the destination which propagates through the network 
to the source. This ends the connection establishment phase 
of the signaling mechanism. Additional signaling messages 
are then required to maintain this connection. The entire 
signaling protocol can be represented by a state diagram for 
each participant of the protocol. Whenever a node sends or 
receives a message, a transition is made from one state to 
another. 

The basic point-to-multipoint connection is a tree-based 
model with a root and several leaves. The connection is 
initiated with the establishment of a point-to-point connec- 
tion from the root to one of the leaves. The address of the 
root node forms a part of the connection identification. 
Additional connections to other leaves are established by 
sending an ADD -PARTY signaling message to each of the 
leaves. Dynamic membership is supported in two ways. In 
the root -initiated join mechanism, the root sends the ADD- 
PARTY message to a leaf that is interested in joining the 
multicast connection. The leaf responds with a CONNECT 
message to indicate success of the connection. 

In the leaf- initiated join(LIJ) mechanism, the root initiates 
a connection with LIJ options. The leaf indicates the will- 
ingness to join the multicast connection by sending a LEAF- 
SETUP-REQUEST message to the network. Since the net- 
work is aware of the UJ connection, it sends a SETUP 
message to the leaf. Successful connection establishment is 
indicated when the leaf sends a CONNECT message to the 
network. Depending on the protocol, the network may or 
may not notify the root about the identity of the joined leaf. 
Similar mechanisms are available to drop a leaf node from 
a particular connection. 

The current UNI signaling mechanisms do not, however, 
address the issue of the establishment of a multipoint-to- 
multipoint connection. One way of implementing this type 
of connection is to use a peer-to-peer model. In this model, 
there is no root node and all the participating nodes have 
similar functions. Some participants are senders or receivers 
alone, while others are both. The group is then logically 
identified by a multicast group address. 
Private Node-Network Interface (PNNI) 

The routing of the signaling messages between ATM 
switches uses the NNI (Node-Network Interface) protocol. 
The main difference between UNI and NNI protocols is that 
NNI protocols have to incorporate routing as well as sig- 
naling. The signaling component of the NNI protocol is used 
to relay connection requests through the ATM network. The 
routing component of the NNI protocol determines the route 
used by the signaling messages to propagate through the 
ATM network. The connection is also established on this 
route and subsequently, the data also flows through this 
route. The routing of signaling messages is similar to a 
connectionless routing protocol because no connection 
exists before connection setup. 

To ensure inter-operability among various ATM switches 
developed by different vendors, the ATM Forum has pro- 
posed a NNI protocol called the Private Node -Network 
Interface protocol. PNNI protocols are based on link-state 
routing protocols like the OSPF protocols. The protocol 
model provides a hierarchical view of the ATM network. In 
this model, the hierarchical graph consists of nodes and 
finks. An example PNNI Architecture 10 is shown in FIG. 1. 
At the lowest level 104 of the hierarchy, the nodes 12 of the 
graph represent the physical switching systems. The links 14 
at the lowest level 104 represent physical links that connect 
the various switching systems. At higher levels 80, 64, the 
nodes 16, 18 are logical nodes, where each logical node 16, 
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18 represents a collection of nodes at the lower level of 
hierarchy. Similarly, a link 20 between two logical nodes is 
a logical link that represents connectivity between the sets of 
nodes represented by the logical nodes. Nodes at each level 
are grouped together to form Peer Groups 22, 24, 26 
(represented by ellipses in FIG. 1). Each peer-group has a 
peer-group leader (PGL). In FIG. 1, the PGLs for peer 
groups 22, 24, 26 are represented by dark nodes 32, 34, 36. 
A PGL has the additional functionality of representing the 
peer-group as a logical node at the higher level of the 
hierarchy. At the lowest level 104, the links 28 that connect 
nodes belonging to different peer groups are called border 
links. The nodes on either side of a border link are called 
border nodes. For example, in FIG. 1, nodes A.2.4 and A.3.2 
are border nodes. 

Similar to OSPF, efficient routes can be computed only by 
collecting information about states of the nodes and the links 
in the network. This information constitutes the topology 
information of the network. The link state includes infor- 
mation like the available bandwidth, the mean delay on the 
link and the peak cell rate that can be supported by the link. 
The node state includes aggregate information about the 
peer-group and the end systems attached to the switching 
system. Each node periodically floods the topology state 
information within its peer-group. Other nodes that belong 
to the peer-group update their databases with this informa- 
tion. Thus, each node in the peer-group has accurate infor- 
mation about the node and link states of all the topology 
elements within the peer-group. The PGL aggregates the 
information of the peer-group and floods this aggregated 
information in the higher level peer-group. Similarly, the 
PGL also collects aggregated information about other peer- 
groups through their respective PGLs. The PGL floods this 
collected information in the lower level peer-group. Thus, 
every node in the lower peer-group updates its database with 
the aggregated information about the nodes in the other 
peer-groups. The maintenance of this information is not very 
difficult even for large networks because only the aggregated 
information is stored in the nodes. This makes the PNNI 
protocol highly scaleable to large networks. The same 
protocol is followed by the nodes at each layer of the 
hierarchy, hence the protocol is termed as recursive. 

The point-to-point routing protocol as specified currently 
is source-based routing. The source has complete informa- 
tion about all the nodes and links within its peer-groups, but 
it has only aggregated information about the nodes and links 
in other peer groups. The source cannot determine the exact 
route to the destination node. Based on the information 
available to it, the source computes a logical path to the 
destination node. This path can involve logical nodes from 
higher layers of the hierarchy. The actual route at each level 
of the hierarchy is determined during the setup of the 
connection. The route depends on the QoS requirements of 
the connection. Signaling messages are used to establish the 
connection and negotiate QoS requirements. 
PNNI Signaling 

Signaling is the mechanism by which the connection is set 
up in a connection-oriented protocol. The signaling incor- 
porates functions like resource reservation, virtual channel/ 
path establishment and QoS negotiations. In PNNI, the 
signaling mechanism is similar to ATM UNI Signaling, 
however, PNNI incorporates additional information like the 
Designated Transit List (DTL), which represents the 
approximate route for setting up the connection. The DTL is 
a set of paths, one for each level of hierarchy. At the lowest 
level of the hierarchy, the path is a physical path between 
two nodes within a peer-group. At higher levels of hierarchy, 
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the paths are logical paths. Within a peer-group, the SETUP 
message traverses along the designated path, until it reaches 
a border node. This border node is called the exit border 
node or the egress node. The edge linking the border nodes 

5 of the two peer-groups is represented as a logical link at a 
higher layer. If this logical link is present in the DTL, the 
SETUP message is passed to the neighboring peer-group 
across the border link. The border node in the neighboring 
peer-group is called the entry border node or the ingress 

10 node. If the destination node is in this peer-group, the ingress 
node computes the path to the destination node and appends 
it to the DTL. Otherwise the ingress node computes the path 
to the border node which has a link to the peer-group that is 
on the path to the destination node. The computed path is 

15 appended to the DTL. The ingress node also stores this path 
information until the connection is set up. Only the source 
node and the ingress nodes can add paths to the DTL. This 
is important during crankback because it can prevent loop- 
ing and unnecessary repeated exploration of failed paths. 

20 Crankback occurs if a node on the pre-determined route is 
not able to find a path through its peer-group. This could be 
because of node or link failures or stringent QoS require- 
ments. This node then informs the ingress node of the 
peer-group that it cannot find a path. The ingress node can 

25 then try alternate routes to reach the destination. The sig- 
naling mechanism stops once the destination node is reached 
or no path is available. If no path is available, the connec- 
tions setup so far are cleared. If the destination node accepts 
the connection, a CONNECT message is sent from the 

30 destination to the source along the established path (in the 
reverse direction). This enables all the ingress nodes to clear 
all the route information, which they have stored to assist 
crankbacks. 

Phase 1 of the PNNI protocol deals primarily with point - 
35 to -point routing and signaling. Phase 2 of the PNNI protocol 
will deal with point-to-multipoint routing. Some work has 
been done in the prior art in this area by F. C. Liaw, ATM 
Group Multicast Routing and Signaling Protocol; Architec- 
ture Overview, ATM Forum draft 94-0995, 1994, wherein 
40 the idea of a core based-tree with multiple core nodes is 
mentioned. Although the idea of multiple core nodes is 
presented here, this paper does not provide the details of the 
routing and signaling mechanisms in a hierarchical frame- 
work. Accordingly, there is a need to develop a highly 
45 scaleable scheme for multicasting in a hierarchical frame- 
work which is also efficient with respect to a combination of 
factors like bandwidth consumption and delay, while guar- 
anteeing some quality-of-service (QoS) for each of the 
connections. 

50 SUMMARY OF THE INVENTION 

Hie present invention extends the PNNI protocols to 
support hierarchical multicast routing and signaling for ATM 
networks. The invention utilizes an ^extension^to^a^core 2 

55 ^se^tree_ algorithm. Instead of a single core node, core 
nodes are maintained^ in each peer-group and at each level of 
the hierarchy. The advantage of this is that one single core 
node is not overloaded. Additionally, this increases fault- 
tolerance because there are no single points of failure. As 

60 would be understood, the present invention is highly scale - 
able because of the hierarchical nature of PNNI. In addition, 
the scheme supports multiple senders and dynamic mem- 
bership changes to the multicast group. Quality of service 
requirements can be negotiated during connection setup and 

65 are guaranteed during the course of the connection. Though 
some additionaI^oj?glogica lgiDfq rmation has to be flooded in 
the peer-groups to 1 cpmpute>efficient multicast routes, the 
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overheads to the connection management are minimal. The 
multicast tree is built incrementally and the cost of the tree 
is comparable to the cost of the Steiner Tree computed using 
some standard heuristics. 

In one embodiment of the invention, a method is set forth 
for multicasting cells in a communications network. The 
communications network includes ar-pluralityzofaiodes 
coupleo^to:one:anothgr^^links and comprises the steps of: 
dividing the communications network into arhierarchical 
arrarjgementroQjeexlgr^ 

atl g^ast-one ofHhe-no des.therein; building a multicast tree for 
a multicast group which includes all participant nodes, 
wherein a participant node is either a sender or receiver of 
data for the multicast group. The step of building including 
the steps of: selecting core nodes for each of the peer groups 
within the multicast group, wherein a node wanting to 
become part of the multicast group mustCregister w ith the 
core node in its peer group; and flooding core node^infor- 
^ationZlocaUyCwithin each of the peer groups, wherein the 
nodes of a peer group need only maintain information about 
the core nodes of direct ancestor peer groups. Cells are able 
to be efficiently multicast by way of said multicast tree to 
said nodes in said multicast group. A peer group leader is 
selected for each of the peer groups in the network for 
caggregatingjo pology-i nformation of nodes in the peer group 
and flooding the topology information in higher level peer 
groups, wherein a list of logical core nodes of ancestor peer 
groups is flooded in a peer group by each said peer group 
leader. 

BRIEF DESCRIPTION OF THE FIGURES 

For a better understanding of the present invention, ref- 
erence may be had to the following description of exemplary 
embodiments thereof, considered in conjunction with the 
accompanying drawings, in which: 

FIG. 1 shows an illustration of a multicast tree within a 
PNNI Architecture and in accordance with the present 
invention; 

FIG. 2 shows an illustration of a multicast tree in accor- 
dance with the present invention after a node joins the 
multicast tree; 

FIG. 3 shows an illustration of the multicast tree after a 
first and second node join; 

FIG. 4 shows an illustration of a multicast tree after a node 
leaves the multicast group; and 

FIG. 5 shows an illustration for an exemplary architecture 
for signaling in accordance with the present invention. 

DETAILED DESCRIPTION 

The present invention describes a methodology for mul- 
ticast routing in the PNNI framework. The scheme is highly 
scaleable to large networks because routers have to maintain 
onl y one^ tree per multicast group. The method supports 

^dynamic.membership to a multicast group, in that, t nodescan 

tjoih:or~lejyjenhe^uJticas^ 

(multicast. Multiple senders to the multicast group are also 
supported, which enables realization of a true multipoint- 
to- multipoint connection. In addition, the multicast tree can 
be dyjgamjc^yjjhanged^ 

linkrslates. The invention also has very low latency, that is, 
the join lime of a new node is significantly small. 

The present invention utilizes an extension of a core based 
tree (CBT) methodology to accomplish the multicast rout- 
ing. One of the drawbacks of CBT algorithms of the prior art 
is that the core node becomes a bottle-neck and a single 
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point of failure. To overcome this drawback, the present 
invention uses more than one core node per multicast group. 
In the PNNI framework, introduction of a core node in each 
of the peer-groups that is within the scope of the multicast 

5 results in a highly modular algorithm. Logical core nodes are 
also introduced at higher levels of the hierarc hy. Using these 
core nodes, /armuHicastztree:3s^rw^ 
participantcnode.sriwherein a participant node is either a 
sender or a receiver of data for the multicast group. The 
selection of core nodes is very crucial because a wrong set 
of core nodes can adversely affect the performance of the 
algorithm. Although the study of various schemes for core 
node selection is beyond the scope of the present invention, 
some criteria has been included which will help in deter- 
mining good^candidates for the core node. 

1S 'Gore^Node-Selection 

When a multicast group is set up, the core nodes for that 
group are also selected, wherein each group has its own set 
of core nodes. Toccomputei. efficient multicast trees, it is 
important to have the right set of core nodes. Border nodes 

20 are good candidates for core nodes. Intuitively, this makes 
sense because border nodes are more likely to be a part of 
the multicast treerNodes:wim;larg"eTaegreaalso.ma^.be^er 
^core:n6des. Since core nodes have to handle high bandwidth, 
it is clear that nodes without sufficient bandwidth are poor 

25 choices as core nodes. It cannot be proven that one of these 
criteria is more important than the other, however, a border 
node with a large degree and sufficient bandwidth seems to 
be the best choice as a core node. As would be understood, 
care must be taken so that the same nodes do not get selected 

30 as the core nodes for several multicast groups, as heavily 
loaded core nodes will adversely affect performance. 

Once the core nodes are selected, core node infoTmatior? 
is flooded locally within each peer-group. A list of logical 
core nodes of ancestor peer-groups is also flooded by the 

35 peer group leader (PGL). The amount of information flooded 
is minimal because the nodes of a peer-group need not 
maintain the information about core nodes of peer-groups 
that are not direct ancestors. This flooding can be incorpo- 
rated along with the flooding of topology state information. 

40 Once selected, it is assumed that core nodes will not change, 
however, as would be understood, this restriction is not 
binding. 

In the present invention, a core node is defined to be active 
if there is a participant node in the same peer-group to which 

45 the core node belongs. The present invention requires that 
the following conditions be met at all times: all active core 
nodes must be on the multicast tree; if there is an interme- 
diate (non-participant node which is on the multicast tree) 
node belonging to a particular peer-group, the corresponding 

50 core node must be on the multicast tree; and if there is no 
participant node in a particular peer-group, the correspond- 
ing core node and intermediate nodes of that peer-group 
must be pruned from the multicast tree, provided it does not 
disconnect the tree. These conditions result in a we 11- 

55 balanced tree and addition and deletions of participant nodes 
can be done with minimal latency. 
Participant-Initiated Join (PIJ) 

In the participant-initiated join (PIJ) mechanism, when a 
node wants to join the multicast group (referred as joining 

60 node), the joining node tries to attach to the core node within 
its peer-group. The shortest path to the core node can be 
easily determined because the node and link states within the 
peer-group are completely known to all nodes in the peer- 
group. A setup message is sent to the core node along this 

65 shortest path. En route, if the message reaches a node that is 
already on the multicast tree, the joining node attaches to 
this particular node and becomes a part of the multicast tree. 
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It can happen that the core node in the peer-group of the 
joining node is not currently on the multicast tree. The core 
node thenjries to join the core node of the parempeer-group. 
The'^routing is recursively J^lo wed'aY~ea ch:ievel of hieTar^ 
chy^unliMn ictive c ore notie or the core node'of ttieTtopmost 
peerrgfoup^is-reached/' This results in the building of a 
backbone tree consisting of active core nodes. The joining 
node along with all the involved core nodes then becomes a 
part of the multicast tree. 

The PIJ mechanism of the present invention can be further 
explained with reference to FIG. 1. FIG. 1 depicts a hier- 
archical network 10 in accordance with the present 
invention, wherein the dark nodes are representative of core 
nodes. A multicast tree is shown, wherein initially the nodes 

A, A.2 and A.2.1 are on the multicast tree. When node A.3.5 
wants to join the multicast tree, it first joins the core node 
within its peer-group 23, that is, node A.3.1. Since A.3.1 
itself is not on the multicast tree, the algorithm is recursively 
executed at the next higher level 80 resulting in the node A.3 
joining the core node A.2. The resulting tree 40 is shown in 
FIG. 2. Now, if node B.2.5 wants to join the multicast group, 
it first joins node B.2,1. At level 80, B.2 joins B.l. Let the 
logical link (B.2-B.1) be represented by the physical link 
(42) B.2.2-B.1.4. At level 104, the physical path (B.2.1, 

B. 2.2, B.1.4,B.1.1) is appended to the multicast tree. Since 
B.l itself is not on the tree, the node B at level 64 joins node 

A. Let the logical link (B-A) be represented by the logical 
link B.1.2-A3.4. This results in the path (B.l. 1,B. 1.2, A.3 .4) 
being appended to the multicast tree. The resulting tree 50 is 
shown in FIG. 3. Nodes B.1.3 and B.1.5 can easily join the 
multicast group by attaching to nodes B.1.2 and B.1.4 
respectively. Thus, the latency of joining improves signifi- 
cantly in this algorithm. 

Deletion of Nodes 

In describing the €ieleti6h^of~nodes? from a multicast 
group, let the multicast tree which connects all the partici- 
pant nodes and the active core nodes be considered as a 
graph. When a participant node, whose degree is more than 
1, tries to leave the multicast group, it remains on the 
multicast tree as an intermediate node. When a participant 
node, whose degree is 1, tries to leave the multicast group, 
it prunes itself from the tree, provided it is not a core node. 
This pruning can result in the degree of the neighbor node 
to become 1. The neighbor node then prunes itself, if it is 
neither the core node nor a participant node. This process is 
repeated, resulting in a cascade of prunes. The cascade 
continues until a participant node or a core node or a node 
with degree more than 1 is reached. 

Whenever a participant node^teaves the multicast group, 
the core node in that peer-group is also informed. If the core 
node finds that there are no more participant nodes within its 
peer-group, it can delete itself from the multicast tree, 
provided it does not disconnect the tree. This is done at the 
logical level as well. The deletion of a logical link results in 
some physical nodes also being deleted. The pruning keeps 
the cost of the tree within reasonable limits, especially when 
there are few participant nodes. 

Referring to FIG. 4, an example is shown with participant 
nodes B.2.5, B.1.3, B.1.5 and A.3.5 for the deletion of nodes 
in the multicast of network 10. As can be seen, if node B.2.5 
wants to leave the multicast group, the nodes B.2.5 and 

B. 2.4 get pruned. At level 80, node B.2 finds that there are 
no participant nodes within the peer-group it represents. So, 
node B.2 prunes itself, resulting in nodes B.2.1 and B.2.2 
pruning themselves from the multicast tree. The resulting 
tree 60 is shown in FIG. 4. Now if B.2.5 wants to rejoin the 
multicast group and the link states have changed, a different 
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path may get appended to the existing tree. This dynamic 
creation of tree helps in satisfying the QoS requirements of 
the connection under varying node and fink states. 
Signaling Mechanisms 
5 In order to addjnpdejp_anjJrcady existing multicast tree 
some sort of signa^lil^rh^ needed . In one embodi- 

ment of the present invention, a peer-to-peer implementation 
is described, however as would be understood by those 
skilled in the art, other ways of implementing the instant 
routing algorithm are available. In the peer-to-peer scheme, 
the multicast group is represented by a logical multicast 
addressjgggfoe^node^ 

^paTnripanYnodesr-T^e The node 

that wants to join the multicast group sends a SETUP 
message towards the core node within its peer-group. The 

35 path to the core node is expressed in terms of a Designated 
Transit List (DTL), as has been explained with respect to 
PNNI Signaling, and as would be understood by a person 
skilled in the art. This is a point-to-point mechanism in the 
sense that one branch is usually added to the existing 

20 multicast tree. Since core nodes are involved, it can happen 
that core nodes also get added to the tree as additional 
branches. Addition of more than one branch to add a single 
node is a distinct feature of the present invention. 
The basic types of messages for the signaling mechanism 

25 of the present invention are a SETUP message, RETRACE 
message, CONNECT message, and RELEASE message. 
The SETUP message originates at the joining node to set up 
a connection. The destination for this message is either a 
node on the multicast tree or the core node in the peer-group. 

30 When this message passes on a link from one node to 
another, resources for the connection are reserved on that 
link. This message carries the Designated Transit List 
(DTL), which is the approximate path to be followed by the 
signaling messages. This path is computed by the source of 

35 the message in source-based routing. In the present 
invention, the DTL created by the source can be modified by 
an ingress node to the peer-group, an egress node to the 
peer-group and a core node of the peer-group. Note that this 
is very different from the PNNI signaling where only the 

40 source and the ingress node can modify the DTL. 

The RETRACE message is a new type of message that 
has information similar to the SETUP message. A key 
difference, however, is that no resources are reserved on the 
links. Further, the RETRACE message traverses only on the 

45 links already traversed by the SETUP message, and in the 
opposite direction. 

The CONNECT message is sent by the node to which the 
joining node attaches. Note that this node must already be a 
part of the multicast tree. The message traverses on all the 

50 links on which resources are reserved. When a node receives 
the CONNECT message, it updates its routing tables to 
indicate the setting up of the connection. 

The RELEASE message can be sent by any of the 
intermediate nodes, in case the connection cannot be 

55 established, or to terminate the connection. This message 
also traverses on all the links on which resources are 
reserved. The resources are released upon receipt of this 
message. 

Upon receiving a particular message, the actions taken by 
60 a node depend on the type of the message. For instance, with 
the SETUP message, if the node is already on the tree, that 
node sends a CONNECT/RELEASE message to the joining 
node, depending on whether the connection is accepted/ 
rejected. The message follows the reverse path to the joining 
65 node. 

If the node is not on the multicast tree, it checks the DTL 
and forwards the message to the next node in the DTL and 
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also forwards the pointer. If the node is an egress border The SETUP message is forwarded to node A3 .2. Since 

node, it saves the list of the nodes visited by the SETUP node A.3.2 is an egress node, it remembers the list of visited 

message and forwards the message across the border link. If no des (namely, nodes A.3.4, A3.1 and A.3.2). It then 

the node is an ingress border node it computes the path to forwards ^ e SETUP message across the border link 204 to 

the core node of the pe^r-group The path is converted to 5 node A 4 4 $ince A 4 4 fe m m Qod {{ com . 

DTL format and pushed onto the stack. The SETUP message . . • , , , A „ , 

is then forwarded according to the new DTL (towards the P_ utes * c ^ (n ° de AA2) ' U{ *»* P&th be 

core node). through A.4,1. The DTL here is as follows: 

If the node is a core node, it first checks if it is active. If (A.4.4, A.4.1, A.4.2) pointer 1 

it is, then it has to be on the tree, wherein this case has been 1Q (A3 A 4 Al) ointer 2 

discussed above. If it is not active, the core node computes L LJm • c , , 

the path to the next peer-group in the DTL. This path is ™ e SETUP 15 forwarded to node A.4.2 through 

converted to a DTL and pushed on to the stack. If any node A 41 Smce AA2 B a ^ node that 15 not acUve and the 

on this path has already been visited by the SETUP message DT L stack is not empty, it computes a path to peer-group 

(this can be found out using the list of visited nodes), the A.l. Let this path go through node A.43. The DTL now 

SETUP message is changed to a RETRACE message. The 15 looks like: 

entries in the DTL are removed until the first entry on the top (A.4.2, A.4.3, A.4.4) pointer 1 

is the visited node and no other entry in the DTL is a visited ' ' 

node. The RETRACE message is forwarded towards the ( A ' 3 ' A * 4 ' A l > P ointer 2 

node from which the SETUP message was received. If there SlDce Qode A 44 has already been visited by the SETUP 

are no visited nodes in the computed path, the SETUP 20 message, the message type is changed to a RETRACE 

message is forwarded as per the new DTL. message and the DTL is changed as follows: 

If the core node is not active and the DTL stack is empty, (A.4.4) pointer 1 

the core node forwards the SETUP message towards the core . . . ^ . 0 

node of the parent peer-group. The path to this core node and ^ ' ^™ . i!, P C . , , , 

the corresponding DTL is computed. Again, a check for a 25 ™ e RETRACE message is forwarded to the node from 

visited node is made. In case a visited node is found, the which the SETUP message was received (node A.4.1) and 

message is changed to a RETRACE and the DTL is modified then t0 A * 4 - 4 - Now the first entrv on t0 P of the stack matches 

as explained above. If no visited nodes are found, the the node ID. Accordingly, a path to peer-group A.1 is 

SETUP message is forwarded as per the new DTL. computed. Since node A.4.4 itself is an egress border node, 

In the case of the RETRACE message, if the first entry on 30 there is no visited nodes in the path. So, the RETRACE 

top of the DTL stack does not match with the node ID or its message is changed to a SETUP message and forwarded 

ancestor ID, the RETRACE message is forwarded towards across the border link to node A. 1.4. Since A. 1.4 is an 

the node from which it received the SETUP message. ingress node, it finds the path to its core node. The DTL now 

If the entry matches, the path (and the new DTL) to the looks like: 

next entry as per the DTL is computed. Again, a check for 35 (A 1 4 A 1 1) pointer 1 

visited nodes is made. If there is a visited node, the DTL is ' 

modified as explained above and the RETRACE message is xuu a i i P oin ^ r . # . 

forwarded towards the node from which it received the u WhenA.1.1 receives the SETUP message, the DTL stack 

SETUP message. If there is no visited node, the RETRACE b u ec ^ Smce n u ode A11 , 1S n f ot active ' lt fonvards 

message is changed to a SETUP message and forwarded to 40 the SETUP message to the core node of its parent peer-group 

tU , , 4 . „ nTi (node A.l). Since we are already in peer-group A.l, the 

the next node as per the new DTL. ^ prrim } . c 1 j ■ 

For the CONNECT/RELEASE message, the resources SETUP mt f a § e * f °™ rde ? C °™ v ™ ^ 

reserved on the link are committed/released. The node peer-group (node B). The path to peer-group B is computed, 

forwards this message on all the links on which a SETUP ^JL th f e P a ' h 8° f 0U S h P^r-groups A.2, A.3 and A.5. The 

was received/sent, except the link on which this CONNECT/ 45 P ^ 

RELEASE is received. It must be noted that this message (A.l.l, A.1.2) pointer 1 

traverses on all the links traversed by the SETUP message, (A.l, A.2, A.3, A.5) pointer 1 

but in the opposite direction. (A,B) pointer 1 

A Signaling Example But, we find that node A.3 has already been visited by the 

Referring to FIG. 5, an exemplary illustration of the 50 SETUP message (this is known to node A.1). SETUP is 

present invention signaling mechanism is shown utilizing changed to the RETRACE message and the DTL is changed 

network 200. As shown in FIG. 5, dark nodes are represen- as follows: 

tative of core nodes. In this example, assume that node B.l.l 3 ^ g\ p^^g,. \ 

is already on the multicast tree. Now, if node A.3.4 wants to ' ' * . 

join the multicast group, it first sends a SETUP message 55 IS^^l • * a a * a a a a 

\ * tl _ j- -. / j a -* *\ rwZ The RETRACE messaee is forwarded to node A. 1.4 

towards the core node in its peer-group (node A.3,1), The L . * ^7 TV \ <* ^ " L L 

SETUP message is forwarded to node A3.1. Since node wmch fo ™ ards V° U AA * and th , en l ° Now I th 5 fi f 

A.3.1 is not active and the DTL stack is empty, the node tries «W °» t0 P of the stack matc e hes the ances !°L 10 °J Q0 ? e 

to join the core node A.l of the parent peer-group. Let the ? 3 ^ pa , lh ? Pf ^fP ' 15 C ^ l f' * r f J S ^ C 

path to core node A.l be through peer-group A.4. The DTL 60 ° £ JL h * exam P le > ^ P alh S° thr0U S h A 3 1 and A * 34 ' ^ 

for the path looks like: DTL for this path is: 

(A.3.1, A.3.2) pointer 1 ( A32 > AJ A34 ) P° mter 1 

(A.3, A.4, A.1) pointer 1 (A.3, A.5) pointer 1 

Along with the DTL, a list of nodes visited by the SETUP (A, B) pointer 1 

message in the current peer-group is also passed along. This 65 Since A3 .4 is already visited by the SETUP message, the 

is used by the ingress, egress and the core node to determine SETUP message is changed to a RETRACE message. The 

loopless paths. DTL is changed to: 
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(A.3.4) pointer 1 
(A.3, A.5) pointer 1 
(A, B) pointer 1 

The RETRACE message is forwarded to the node from 
which node A3 2 received the SETUP message (node 
A3.1). From node A.3.1, the RETRACE message is for- 
warded to A.3.4. Now, the first entry on top of the stack 
matches the node ID. So, a path to peer-group A.5 is 
computed. The message is changed to SETUP since there are 
no more visited nodes. The SETUP message is now for- 
warded to node A.5.1. A. 5.1 is a core node and the DTL 
stack is not empty. So, the path to peer-group B is computed. 
The SETUP message is then forwarded to node A.5 .4 and 
then to node B.1.3. 

Since node B. 1.3 is an ingress node, it computes the path 
to its core node (node B.l.l). When B.1,1 receives the 
SETUP message, it is already active (on the multicast tree). 
So, it sends a CONNECT message towards the node A3 .4. 
This message passes through all the links on which the 
resources were reserved. When the message reaches node 
A.3.4, the connection is established. 

The signaling mechanism of the present invention is 
advantageous in that loop-free connections are created when 
a new node joins the multicast tree. For proof of the instant 
assertion, consider a particular peer-group at the lowest 
level. Paths are added to the DTL only under the following 
circumstances: 

(i) A SETUP message reaches the ingress node. 

Since the ingress node is the only visited node in the 
peer-group at this stage, any path added to the DTL 
cannot create a loop. 

(ii) A SETUP message reaches the core node. 

If the added path has a visited node, a RETRACE 
message is forwarded on the reverse path till the 
visited node is reached. This eliminates the possibil- 
ity of a loop being created. 

(iii) A RETRACE message reaches the egress node. 

If the added path has a visited node, a RETRACE 
message is forwarded on the reverse path till the 
visited node is reached. This eliminates the possibil- 
ity of a loop being created. 
As can be seen, none of the above conditions create a 
loop. Since this argument can be recursively extended to all 
levels of the hierarchy, the signaling mechanism thus 
ensures that the established connection is loop-free. As 
would be understood, similar mechanisms can be used for 
deleting a node from the multicast tree. 

An attractive feature of present invention multicast rout- 
ing scheme is its simplicity. Since nodes at each level follow 
the same algorithm, the invention is very easy to implement. 
Very little information about the membership to multicast 
groups is required to determine a path. Only the list of core 
nodes of the peer-group and its ancestors is flooded within 
a peer-group. Therefore, there is minimal overhead with the 
implementation. 

A perceived disadvantage to the present invention is that 
the signaling mechanism involves different message types 
and appears somewhat complicated. Also, the condition that 
active core nodes have to be a part of the multicast tree can 
result in skewed trees, wherein skewed trees lead to waste in 
bandwidth. This happens when there are very few partici- 
pant nodes and the core nodes are far from the participant 
nodes. The signaling mechanism of the present invention, 
however, ensures that there are no loops whenever a node 
joins an already existing multicast tree. Moreover, the cost 
of the tree generated by this algorithm is not far off from the 
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cost of the pseudo-optimal tree generated by Steiner 
heuristics, and the tree satisfies the property that all nodes 
with degree I are either destination nodes or core nodes. 

From the above, it should be understood that the embodi- 
5 ments described, in regard to the drawings, are merely 
exemplary and that a person skilled in the art may make 
variations and modifications to the shown embodiments 
without departing from the spirit and scope of the invention. 
All such variations and modifications are intended to be 
10 included within the scope of the invention as defined in the 
appended claims. 

What is claimed is: 

1. A method for multicasting cells in a communications 
network, said communications network including a plurality 
15 of nodes coupled to one another by links, said method 
comprising the steps of: 

dividing said communications network into a hierarchical 
arrangement of peer groups including logical peer 
groups representative of a collection of nodes at a lower 
20 level of said hierarchical arrangement, wherein a peer 
group includes at least one of said nodes therein; 
building a multicast tree for a multicast group of nodes in 
said network which includes all participant nodes 
involved in a multicast, wherein a participant node is 
25 either a sender or receiver of data for said multicast 
group, said step of building including the steps of: 
selecting core nodes for each of said peer groups within 
said multicast group, wherein a node wanting to 
become part of said multicast group must register 
30 with a core node in its peer group; 

flooding core node identity information locally within 
each of said peer groups including said logical peer 
groups, wherein said nodes of a peer group need only 
maintain said identity information about said core 
35 nodes of direct ancestor peer groups; and 

selecting a peer group leader for each of said peer 
groups in said network for aggregating topology 
information of nodes in said peer group and flooding 
said topology information in higher level peer 
40 groups, said peer group leader flooding collected 

topology information from higher level peer groups 
into lower level peer groups, said collected topology 
information including a list of logical core nodes of 
ancestor peer groups for each said multicast group, 
45 wherein said peer group leader may be a different 

node than said core node in a peer group, 
wherein said cells are able to be efficiently multicast by 
way of said multicast tree to said nodes in said 
multicast group. 
50 2. The method of claim 1, wherein said communications 
network is an ATM network and said cells are ATM cells. 

3. The method of claim 1, wherein a core node is active 
if a participant node is in the same peer group to which the 
core node belongs, and further including requiring all active 

55 core nodes of a specific multicast group to be part of said 
multicast tree for said specific multicast group. 

4. The method of claim 3, further including requiring a 
core node to be part of said multicast tree if an intermediate 
non-participant node on the multicast tree belongs to that 

60 same peer group. 

5. The method of claim 4, further including pruning a 
corresponding core node and corresponding intermediate 
non-participant nodes from said multicast tree if there is no 
participant node in the corresponding peer group, and if said 

65 pruning does not disconnect said multicast tree. 

6. The method of claim 1, wherein said topology infor- 
mation includes node and link state information. 
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7. The method of claim 1, further including attaching a 
non-core node wanting to join said multicast group to said 
core node within its peer group, wherein said core node joins 
the core node of a parent peer-group on said multicast tree 
in a recursive fashion if said core node is not part of said 
multicast tree. 

8. The method of claim 1, wherein a non-core participant 
node leaving said multicast tree removes itself and a link 
between said non-core participant node and its neighbor, 
provided said non-core participant node has exactly one 
neighbor; 

wherein if said non-core participant node has more than 
one neighbor, it remains on said multicast tree as a 
non-participant node, and a core node with no partici- 
pant nodes in its peer group leaving said multicast tree 
is required to prune itself therefrom provided said 
pruning does not disconnect said multicast tree. 

9. The method of claim 1, further including the steps of: 
sending a SETUP message from a node wanting to join 

said multicast group towards a core node within its peer 
group; and 

reserving resources on a link for a connection, when a 
SETUP message passes on said link from one node to 
another, a path to said core node being expressed in 
terms of a designated transit list (DTL), where said 
DTL is an approximate path to be followed by signaling 
messages. 

10. The method of claim 9, wherein said DTL created by 
a source can be modified by an ingress node to the peer- 
group, an egress node to the peer-group and a core node of 
the peer-group. 

11. The method of claim 9, further including sending a 
RETRACE message, wherein said RETRACE message 
traverses only on links already traversed by a SETUP 
message in an opposite direction. 

12. The method of claim 9, further including sending a 
CONNECT message, wherein said CONNECT message is 
sent by a node to which a joining node attaches, said 
CONNECT message traversing on all the links on which 
resources are reserved. 

13. The method of claim 9, further including sending a 
RELEASE message, wherein said RELEASE message may 
be sent by any intermediate nodes, in case a connection 
cannot be established, said RELEASE message also being 
sent to terminate a connection, wherein said RELEASE 
message traverses on all the links on which resources are 
reserved. 

14. The method of claim 9, wherein upon receiving said 
SETUP message, if the node is not on the multicast tree, said 
node checks the DTL and forwards a message to a next node 
in the DTL with a pointer, wherein if said node is an egress 
border node, said node saves a list of the nodes visited by 
said SETUP message and forwards said list across a border 
link, and wherein if said node is an ingress border node, said 
node computes a path to a core node of the peer-group, said 
path being converted to a new DTL and pushed onto a stack, 
wherein said SETUP message is then forwarded according 
to the new DTL towards the core node. 

15. The method of claim 9, wherein upon receiving said 
SETUP message, if the node is a core node, said core node 
first checks if it is active, wherein if not active, said core 
node computes a path to a next peer-group in the DTL, 
wherein said path is converted to a new DTL and pushed 
onto a stack, and wherein if any node on said path has 
already been visited by said SETUP message, said SETUP 
message is changed to a RETRACE message. 

16. The method of claim 15, wherein entries in the DTL 
are removed until a first entry on the top of said stack is a 
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visited node and no other entry in the DTL is a visited node, 
said RETRACE message being forwarded towards a node 
from which said SETUP message was received, wherein if 
there are no visited nodes in said path, said SETUP message 

5 is forwarded as per said new DTL. 

17, The method of claim 9, wherein upon receiving said 
SETUP message, if a core node is not active and the DTL 
stack is empty, said core node forwards said SETUP mes- 
sage towards a core node of a parent peer-group, wherein a 

3Q path to a core node of said parent peer-group and a corre- 
sponding new DTL is computed and a check for a visited 
node is made, wherein if a visited node is found, said SETUP 
message is changed to a RETRACE message and the DTL 
is modified, and wherein if no visited nodes are found, the 
SETUP message is forwarded as per the new DTL. 

15 18. The method of claim 11, wherein upon receiving a 
RETRACE message, if a first entry on top of the DTL stack 
does not match with a node ID or an ancestor ID, the 
RETRACE message is forwarded towards a node from 
which it received the SETUP message, wherein if the entry 

20 matches, a path to a next entry as per the DTL is computed, 
a check for visited nodes being made, wherein if there is a 
visited node, the DTL is modified and the RETRACE 
message is forwarded towards the node from which it 
received the SETUP message and if there is no visited node, 

25 the RETRACE message is changed to a SETUP message 
and forwarded to the next node as per the new DTL. 

19. The method of claim 12, wherein for said CONNECT 
message, resources that are reserved on a link are 
committed, the node forwarding said message on all the 
links on which a SETUP was received, with the exception of 
a link on which said CONNECT is received. 

20. The method of claim 13, wherein for said RELEASE 
message, resources that are reserved on a link are released, 
the node forwarding said message on all the links on which 
a SETUP was received/sent, with the exception of a link on 

35 which said RELEASE message is received. 

21. A shared communications network for multicasting 
cells, said communications network including a plurality of 
nodes coupled to one another by links, said network com- 
prising: 

40 a hierarchical arrangement of peer groups making up said 
communications network, wherein a peer group 
includes at least one of said nodes therein; 
one or more multicast trees for a multicast group of nodes 
in said network, which multicast trees include all 

45 participant nodes involved in a multicast, wherein a 
participant node is either a sender or receiver of data for 
said multicast group; 

a core node selected for each of said peer groups within 
said multicast group, wherein a node wanting to 

SO become part of said multicast group must register 

with said core node in its peer group, wherein core 
node identity information is flooded locally within 
each of said peer groups, and said nodes of a peer 
group need only maintain said identity information 

55 about said core nodes of direct ancestor peer groups; 

and 

a peer group leader for each of said peer groups in said 
network for aggregating topology information of 
nodes in said peer group and flooding said topology 
eo information in higher level peer groups, wherein a 

list of logical core nodes of ancestor peer groups is 
flooded in a peer group by each said peer group 
leader, wherein said peer group leader may be a 
different node than said core node, 
65 wherein said cells are able to be efficiently multicast by 
way of said multicast tree to said nodes in said multi- 
cast group. 



05/15/2004, EAST Version: 1.4.1 



5,831,' 

17 

22. The network of claim 21, wherein said communica- 
tions network is an ATM network and said cells are ATM 
cells. 

23. A method for multicasting cells in a communications 
network, said communications network including a plurality 5 
of nodes coupled to one another by links, said method 
comprising the steps of: 

dividing said communications network into a hierarchical 
arrangement of peer groups, wherein a peer group 
includes at least one of said nodes therein; 10 

building a multicast tree for a multicast group of nodes in 
said network which includes all participant nodes 
involved in a multicast, wherein a participant node is 
either a sender or receiver of data for said multicast 
group, said step of building including the steps of: 15 
selecting core nodes for each of said peer groups within 
said multicast group, wherein a node wanting to 
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become part of said multicast group must register 
with a core node in its peer group; 
flooding core node identity information locally within 
each of said peer groups, wherein said nodes of a 
peer group need only maintain identity information 
about said core nodes of direct ancestor peer groups; 
and 

selecting a peer group leader for each of said peer 
groups in said network for aggregating topology 
information of nodes in said peer group and flooding 
said topology information in higher level peer 
groups, wherein a list of logical core nodes of 
ancestor peer groups is flooded in a peer group by 
each said peer group leader. 

***** 
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